Some database systems have an application call that can request a change to a database without locking the data at the time of the request. Instead, the processing of the update request is deferred until the application issues a commit point. For example, a database management system may defer the processing of an update request call until commit time. No locks are held and no changes are made to the database regarding the update request at the time of the request call. In fact, the same or another application may make changes to the same segment or row in the database via other non-deferred update requests that do lock the data. At commit time, the deferred update request is processed based on the current data in the database at commit time. At this time the segment or row can be set to a specific value or changed as requested by the deferred update.
The database system further captures and makes available information about updates made to the database, so that they might be replicated on some other database or table. Change capture processing normally collects information about the call at the time that the application makes the update request. In database systems where the data is locked and therefore will not change outside the scope of the current transaction, the information required for capturing the change is available at the time the call is processed. However, in a database system where the update is deferred until a commit point, the physical data information (i.e. the before and after images) is not available at the time the call is made. Further, during commit point processing, when the deferred update request is processed, not all of the call information may be available.